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SYSTEM AND METHOD FOR PROVIDING EVENT HYSTERESIS 
IN NETWORK MANAGEMENT SYSTEMS 

CROSS REFERENCE TO RELATED APPLICATIONS 

5 The present application claims the benefit of the filing date of U.S. Application Ser. 

No. 60/484,505, filed July 2, 2003, the teachings of which are incorporated herein by 
reference. 

FIELD OF THE INVENTION 

10 The present invention relates to Network Management Systems (NMS), and, in 

particular, to a system and method incorporating hysteresis principles when processing 
events, such as an alarm, in a network management system. 

BACKGROUND 

15 NMS systems are employed in a variety of network types to conduct system-level 

management of the elements of the network. Generally, a NMS performs functions 
including: alarm/fault management, performance management, configuration management, 
security management and business/account management. These systems may receive or 
request information from the underlying network elements, and provide management 

20 information to a network administrator through a user interface. A network administrator may 
also actively manage the configuration of the network and/or network elements through the 
user interface. 

In networks such as Wavelength Division Multiplexing (WDM) optical 
communication networks, event management, e.g. alarm management, is a crucial function of 
25 the NMS. In the case of alarm reporting, for example, any alarms reported by a network 



element must be accurately reported with minimized latency so that a network administrator 
may take corrective action. Delays in reporting alarms can lead to unnecessary system failure 
and loss of network traffic. Inaccurate reporting, e.g. as to the time and/or location of a fault, 
can also lead to delays in system repair, Service Level Agreement (SLA) violations, and/or 
5 unnecessary remedial effort. 

Known NMS configurations immediately report all alarms reported by all network 
elements. A problem arises, however, when reported alarms toggle between states. This can 
occur in an optical communication network when performance criteria for a network element, 
e.g. bit error rate, FEC error count, laser current, etc., intermittently moves between 

10 acceptable and unacceptable levels, or when a network element is on the verge of failure and 
generates frequent clearing alarm(s). Forwarding each state change of toggling alarms to a 
network administrator can cause serious NMS performance and capacity problems, which can 
even lead to paralyzing the whole NMS through alarm event report flooding. Other impacts 
include response time degradations, service denial, and overwhelming the network 

15 administrator with unimportant information. 

Accordingly, there is a need for a system and method for managing toggling events, 
such as alarms, in an NMS that can prevent performance degradation caused by an excessive 
number of processed events, while still reporting critical events to the network administrator 
with minimal latency. 

20 

SUMMARY OF THE INVENTION 

A system consistent with the invention includes a variety of aspects. According to 
one aspect of the invention there is provided a method of managing an event toggling 
between first and second event states in the NMS. The method includes: determining if the 
25 event maintains one of the first and second states for a predetermined amount of time; and 
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reporting the maintained one of the first and second states when the one of the first and 
second states is maintained for the predetermined amount of time. In one embodiment, if the 
toggling event, e.g. an alarm, is reported as active, and if it remains cleared for a 
predetermined amount of time it is reported as cleared. 
5 According to another aspect of the invention, there is provided a machine readable 

medium whose contents cause a system to perform a method of managing an event toggling 
between first and second event states in a network management system including: 
determining if the event maintains one of the first and second states for a predetermined 
amount of time; and reporting the maintained one of the first and second states when the one 
10 of the first and second states is maintained for the predetermined amount of time. A NMS 
and an optical communication system are also provided. 

BRIEF DESCRIPTION OF THE DRAWINGS 

For a better understanding of the present invention, together with other objects, 
15 features and advantages, reference should be made to the following detailed description 
which should be read in conjunction with the following figures wherein like numerals 
represent like parts: 

FIG. 1 is a block diagram of an exemplary optical communication system consistent 
with the present invention; 
20 FIG. 2 is a block flow diagram of an exemplary method of managing toggling alarms 

consistent with the invention; 

FIG. 3 is a block flow diagram of another exemplary method of managing toggling 
alarms consistent with the invention; 

FIG. 4 is a flow chart illustrating one exemplary embodiment for automatically 
25 updating a hysteresis table for an alarm consistent with the invention; and 
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FIG. 5 is a flow chart illustrating one exemplary embodiment for clearing stable 
alarms consistent with the invention. 

DETAILED DESCRIPTION 

5 For simplicity and ease of explanation, the present invention will be described herein 

in connection with various exemplary embodiments thereof associated with toggling alarms, 
a subset of the more generic toggling event scenario in an optical communication network. 
Those skilled in the art will recognize that the features and advantages of the present 
invention may be implemented in a variety of network types and configurations. In addition, 
10 the invention is not limited to management of toggling alarms, and is applicable to 
management of any event on a network having a toggling state. It is to be understood, 
therefore, that the embodiments described herein are presented by way of illustration, not of 
limitation. 

In general, a system and method consistent with the invention manages toggling 
15 events, e.g. alarms, in an optical network by providing a hysteresis feature in the alarm 
reporting function of the NMS. In one embodiment, toggling alarms are reported as active or 
set alarms to the NMS as soon as they are received from the network elements. These alarms 
are periodically monitored for state changes. If another event is received indicating that the 
alarm state is cleared, the system observes the alarm for a period of time, the alarm stable 
20 time, to ensure that the alarm is really stable (e.g. cleared). If no additional alarm state 
changes occur within the alarm stable time, the alarm is reported as clear, with the clear time 
being the time when the alarm had its last state change. Advantageously, a system and 
method consistent with the invention may also report that an active alarm is, or is not, a 
toggling alarm, and also may report the number of times an alarm toggled before it finally 
25 was cleared and stayed cleared for the alarm stable time. 

4 



This feature advantageously prevents the NMS internal processes from becoming 
overwhelmed with state changes of toggling alarms, so that the performance of the NMS is 
not impacted and the user is not flooded with useless information concerning toggling alarms. 
The important information that an active alarm is in a toggling state may still be provided to 
5 the network user. This approach may be implemented with any network event, and is not 
limited to alarm reporting. Toggling of other network events (such as, relay state changes) 
may be managed in the same way by simply defining a stable state for the event, e.g. in a 
stable state configuration table which also contains the default state for each event type. 

Turning now to FIG. 1, there is illustrated an exemplary optical communication 
10 system 100 consistent with the present invention. Those skilled in the art will recognize that 
the system 100 has been depicted in a highly simplified form for ease of explanation. It is to 
be understood that the present invention is not limited to illustrated exemplary embodiments 
described herein. In fact, the present invention may be incorporated into a wide variety of 
optical networks, systems and devices without departing from the spirit and scope of the 
15 invention. 

The optical communication system 100 includes transmitter/receiver terminals 103, 
104 connected via an optical information channel 106 supporting bi-directional 
communication. For clarity, the terminal 103 is generally described and illustrated in FIG. 1 
as a transmitting terminal and the terminal 104 is illustrated and generally described as a 

20 receiving terminal. Of course, in a bi-directional communication system, both terminals 103, 
104 may serve as transmitting and receiving terminals and, as such, each includes both 
transmitters and receivers and associated multiplexers and de-multiplexers, monitoring 
equipment, power feed equipment and discrete relay closures used for monitoring and control 
of other equipment. Change of states of these relay closures (e.g. open/close) generate events 

25 with a default state equivalent to the provisioned relay (e.g. normally open or normally 
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closed). Depending on system characteristics and requirements, the optical information 
channel 106 may include one or more optical fiber paths 108, optical amplifiers 110, 
regenerators, optical filters, dispersion compensating modules, and other active and passive 
components. A variety of configurations for each of these elements will be known to those 
5 skilled in the art. 

The transmitting terminal 103 includes optical transmitters 112, 114 ... 116 for 
transmitting optical communication channels at associated wavelengths, e.g., X u A-2 ^n- 
Multiplexer 118 combines these signal into an aggregate signal that is launched into the 
optical fiber path 108 for transmission to the receiving terminal 104. The transmitting 

10 terminal 103 also includes other managed elements 117, such as power feed equipment, 
monitoring equipment and relay closures. 

At the receiving terminal 104, demultiplexer 120 demultiplexes the aggregate signal 
and routes the channel wavelengths, e.g. X u ^2 ■•■ to receivers 122, 124, 126, respectively. 
Similarly, the terminal 104 may also include a multiplexer for combining signals into an 

15 aggregate signal that is launched into an optical fiber path for transmission to a demultiplexer 
in the transmitter/receiver terminal 103. The receiving terminal 104 also includes other 
managed elements 127, such as power feed equipment, monitoring equipment and relay 
closures. 

A NMS 102 may include a processor 130 and machine-readable media 132 and may 
20 be coupled to the network to receive or request information from the network elements and 
provide management information to a network administrator through a user interface 134. 
The machine-readable media 132 may store software instructions for execution by the 
processor to allow active management of the configuration of the network and/or network 
elements through the user interface 134. The NMS 102 may provide any of a variety of 
25 known network element management functions, and may be adapted to suit the particular 
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network it is intended to manage. Those skilled in the art will recognize that there are a 
variety of configurations for alarm or event reporting by the various network elements. The 
network elements may report internal alarms corresponding to localized faults, alarms 
associated with data received or transmitted, e.g. loss of optical signal, high BER, etc., and/or 
5 event state changes associated with relay closure state changes. 

Advantageously, a NMS 102 consistent with the invention may provide an event 
hysteresis function consistent with the invention for managing toggling events, e.g. alarms, 
on the network. FIG. 2 is a block flow diagram of one exemplary embodiment 200 of a 
method consistent with the invention. The block flow diagrams used herein to describe 

10 various embodiments include particular sequences of steps. It can be appreciated, however, 
that the sequence of steps merely provides an example of how the general functionality 
described herein can be implemented. Further, each sequence of steps does not have to be 
executed in the order presented unless otherwise indicated. In the illustrated embodiment, the 
NMS monitors 202 a toggling alarm reported to the NMS from the network. If the alarm 

15 maintains one state for at least a predetermined period of time, the alarm is deemed stable and 
the stable state is reported 204 by the NMS. 

FIG. 3 is a block flow diagram of another exemplary embodiment 300 of a method 
consistent with the invention. In the illustrated embodiment, a toggling alarm is reported 302 
by the NMS as being set/active. The toggling alarms may be periodically scanned 304 for 

20 state changes. If the alarm state changes to cleared and remains cleared for at least a 
predetermined amount of time, i.e. the alarm stable time, the alarm is deemed stable and is 
reported 306 as cleared by the NMS. The alarm may be reported as cleared at the time of the 
last state change, i.e. not at the end of the alarm stable period, to provide accurate information 
as to when the alarm actually cleared. The number of times that the alarm toggled may also 

25 be reported. 



7 



Some alarms may be treated differently than others in a system consistent with the 
invention. It may be desirable to avoid application of a hysteresis feature for some alarms. 
In the case of FEC threshold-crossing alarm clears, for example, it may be required to report 
the alarm clears as soon as they are reported from a network element. To facilitate immediate 
5 reporting of these alarms, the pre-determined stable time associated with the alarm may be set 
to zero (0). 

Also, it may be desirable to designate a longer or shorter alarm stable time for some 
alarms compared to others. To accommodate this, default treatment characteristics may be 
implemented in software for handling each alarm, e.g. on an element-by-element, event-by- 

10 event, or alarm-by-alarm basis. The default treatment characteristic for each alarm may be 
defined in an associated record including an alarm ID, optionally the network element (NE) 
where the alarm occurred, the alarm stable time for the alarm, and a hysteresis treatment type. 
A default alarm stable time may be, for example, 10 seconds. The hysteresis types may 
include; "Normal" for normal hysteresis treatment with the defined alarm stable time; and 

15 "Suppress" which may cause the hysteresis function to not report any state changes. 

The hysteresis function may be configured for selectively varying the default 
treatment characteristics for a particular alarm or group of alarms. In one embodiment, the 
hysteresis settings for a particular alarm or group of alarms may be configurable in a 
configuration file. For example, the configuration file may facilitate changing the alarm 

20 stable time (e.g. between 0 and 60 seconds, where 0 disables hysteresis treatment) or the 
hysteresis treatment type. The settings for alarms or groups of alarms may be defined in the 
configuration file based on a network element type or ID. For example, a setting may be 
configured for particular cable and/or network element. Also, the default alarm stable time 
may be configured by defining a group including all network elements and setting a new 
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alarm stable time. If no configuration file is found for a particular alarm, the default 
hysteresis setting may be applied. 

Additional configuration settings are possible. For example, the hysteresis 
functionality may be set in the configuration file to depend on environmental variables. Also, 
5 the configuration file may be used to instruct an alarm or group of alarms to be treated in 
accordance with the configuration file for another alarm or group of alarms. Also, the time 
period for checking the state of each toggling alarm may be modified, and a default alarm 
stable time may be set in the configuration file and be modified by other configuration 
settings. 

10 To facilitate alarm management, a hysteresis table may be established for listing all 

un-stable, i.e. toggling, alarms. The table may be updated automatically. FIG. 4 is a flow 
chart illustrating the flow for one exemplary embodiment 400 of a method of automatically 
updating a hysteresis table consistent with the invention. As shown, the alarm state may be 
received 402 from a network element. If the received alarm is already entered in a hysteresis 

15 table 404, the illustrated process flow ends 412 with an update of the table to reflect the state 
and time of the last state change 408. Otherwise, an entry for the alarm may be added 406 to 
the table. If the alarm is not active 410, the process flow ends 412. If the alarm is active 410, 
the process flow ends 412 with communication of an alarm set notification 414. 

Again, in one embodiment, unstable alarms may be reported as set/active. As soon as 

20 an unstable alarm maintains a cleared state for a predetermined alarm stable time, it may be 
removed from the hysteresis table. FIG. 5 is a flow chart illustrating one exemplary 
embodiment for clearing stable alarms from a hysteresis table consistent with the invention. 
In the illustrated exemplary embodiment, process flow begins 500 with setting the cursor to 
the first hysteresis table element 502. If the table is empty or all elements have been 

25 processed 504, then the process flow ends 506. Otherwise, if the last state change time plus 
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the alarm stable time, t, associated with the alarm is not less than the current time 508, then 
the alarm is deemed unstable and the table entry associated with the alarm is left 510 in the 
table. The table cursor is then moved 512 to the next table element. 

If the last state change time plus the alarm stable time, t, associated with the alarm is 
5 less than the current time 508, then the alarm is deemed stable and the entry for the alarm is 
removed 514 from the table. If the alarm state is cleared 516, an alarm clear notification is 
sent 518. Then the table cursor is moved 512 to the next table element. The process flow 
moves through each table element to end 506 after the last entry. The process may be 
repeated periodically to remove unstable alarms at a desired frequency. 

10 It will be appreciated that the functionality described for the embodiments of the 

invention may be implemented using hardware, software, or a combination of hardware and 
software. If implemented in software, a processor and machine-readable medium are 
required. The processor can be any type of processor capable of providing the speed and 
functionality required by the embodiments of the invention. For example, the processor 

15 could be a processor from the Pentium® family of processors made by Intel Corporation, or 
the family of processors made by Motorola. Machine-readable media include any media 
capable of storing instructions adapted to be executed by a processor. Some examples of 
such media include, but are not limited to, read-only memory (ROM), random-access 
memory (RAM), programmable ROM (PROM), erasable programmable ROM (EPROM), 

20 electronically erasable programmable ROM (EEPROM), dynamic RAM (DRAM), magnetic 
disk (e.g. floppy disk and hard drive), optical disk (e.g. CD-ROM), and any other device that 
can store digital information. In one embodiment, the instructions are stored on the medium 
in a compressed and/or encrypted format. 

As used herein, the phrase "adapted to be executed by a processor" is meant to 

25 encompass instructions stored in a compressed and/or encrypted format, as well as 
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instructions that have to be compiled or installed by an installer before being executed by the 
processor. Further, although the processor 130 and a single machine readable medium 132 
are illustrated as being local to the NMS 102 in FIG. 1, the processor and/or machine- 
readable medium may be part of a larger distributed system that may contain various 
5 combinations of machine-readable storage devices, which are accessible by the processor 
through various I/O controllers and which are capable of storing a combination of computer 
program instructions and data. 

The embodiments that have been described herein, however, are but some of the 
several which utilize this invention and are set forth here by way of illustration but not of 
10 limitation. It is obvious that many other embodiments, which will be readily apparent to 
those skilled in the art, may be made without departing materially from the spirit and scope of 
the invention as defined in the appended claims. 
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